1. Field of the Invention
The present invention relates to techniques for testing compliance of a device with a bus protocol.
2. Description of the Prior Art
When developing components for integration into a system, a number of test procedures are typically performed to ensure that the component will operate in the desired manner when integrated into the system. Often the system will consist of a number of individual components connected together via one or more buses. The bus specification will often provide a standard interface to each component, and hence enables the component supplier to design and test the component without any knowledge of the system into which the component will finally be integrated.
However, when developing a component for connection within a system to a bus conforming to a particular bus specification, it is clearly necessary to check that the component will interface with the bus in accordance with the defined bus specification.
The development of a hardware component typically takes place in a number of stages. Firstly, the functional operation/behaviour of the component is defined, for example using a Register Transfer Language (RTL). Two popular RTLs used are VHDL and Verilog. In addition, prior to performing such RTL coding, a behavioural model may be built using a UML (Universal Modelling Language) to validate at a transactional level that the design intent is correct.
Once an RTL representation of the hardware component has been developed, this is then synthesised into a sequence of hardware elements using any of a number of known synthesising tools. The result of the synthesis is a hardware design that can then be used to produce the actual hardware component, for example using appropriate fabrication of the component on silicon. It would clearly be very costly to perform test procedures on the component once it has actually been reduced to hardware, and instead rigorous testing of the RTL representation of the component is typically performed to ensure that the actual hardware generated from that RTL representation will operate correctly.
Hence, the process of checking that a component will interface correctly with a known bus specification will typically be applied to the RTL representation of the component to check that it conforms with the bus protocols defined by the bus specification. There are a number of known techniques for performing such protocol checking.
Firstly, an RTL testbench can be created in which the RTL representation of the component to be tested, hereafter referred to as the device under test (DUT), is incorporated. Further, RTL representations of other devices are also prepared and connected together with the RTL representation of the DUT via the bus to form a system simulation within the RTL testbench. Stimuli are then typically driven across the bus from one device to another, with the resulting waveforms observed either by visual inspection, or by a self checking mechanism or module integrated into the system simulation. This process enables transactions defined by the bus protocol to be checked, and typically the checks will be repeated in an exhaustive manner until all bus protocol transactions are score-boarded correctly.
Another technique that may be used for checking for compliance with the bus protocol in an RTL testbench as described above is to build a sophisticated bus follower in RTL, and to then monitor bus traffic ensuring that the state machine inside the bus follower matches that observed in the actual system simulation at any valid point.
Another alternative way of checking for compliance is to use integration test code to cause a master device to perform read and write transactions across the bus to a slave device, and to then check that the target data is read and/or written correctly. A master device can be considered to be a device that is designed to initiate transfer requests via the bus, whilst a slave device can be considered to be a device which is a recipient of such transfer requests. As an example, a processor core may be used as a master device, and arranged to read from memory the integration test code, and to then execute that test code to perform a predetermined sequence of read and write transactions to check compliance with the bus protocols. Such sequences of code can also be executed so as to cause arbitration between devices and to provoke certain responses from devices in order to check other aspects of the bus protocol. This approach is less satisfactory than either of the two earlier described approaches, since it is typically relatively slow, and does not monitor the bus protocol directly, but rather makes assumptions about compliance with the bus protocol by monitoring results of actions invoked via the bus. Nevertheless, this approach is still currently used as a form of testing device interconnection across the bus.
Another known technique for performing protocol checking which may be used as an alternative to the RTL testbench approach described earlier is to use an HVL (High level Verification Language) development tool, for example Vera or Specman, to monitor bus transactions at an abstract level. Instead of having to produce RTL representations of each device within a system simulation, the HVL development tool can be used to model devices without writing them in RTL. It can then monitor the bus transactions by recording abstract information, for example transfer started, transfer in progress, etc.
As will be appreciated by those skilled in the art, when using any of the techniques described above, the process of testing a specific master device or slave device, or a combination of master and slave devices, is a time consuming process, especially considering the numerous configurations and capabilities of each device, for example a master device that can only support incrementing bursts, a slave device that is not capable of accepting write transactions, etc. Considering the first two techniques described, a degree of configuration could be added to the stimulus generation or the RTL bus follower to cater for these parameters, but the RTL testbench will still typically only be able to test a DUT implemented in a particular RTL, for example VHDL or Verilog. Hence, as an example, if a Verilog testbench is built for a Verilog DUT, typically a VHDL testbench for verifying a VHDL version of the DUT will also be required. Further, when certain bus activity is required to be observed such as a bus handover or an early burst termination, this can be quite difficult to provoke without dedicated RTL to perform the task, thus adding to the time required to design and verify a device.
The HVL development tool approach alleviates the problem of RTL language dependence, but a high degree of skill is required to implement the required checking routines. Further, even if such checking routines were implemented as library modules for re-use, configuration and debugging of each checking environment is still required.
According, it would be desirable to provide an improved technique for testing compliance of a device with a bus protocol.